| 概要 | |
|---|---|
|
ファイル:
\Examples\Acquisition\DataForwarding\iF2D100\DFExample_Host.vad
|
![]() |
|
デフォルトプラットフォーム: iF2D100 |
|
|
簡単な説明 imaFlex 2 Dual 100 プラットフォームにおけるデータ転送(Data Forwarding)の実装について説明します。 |
|
フレームグラバーをデイジーチェーン接続した一般的なデータ転送環境は次のようになります。
左側の最初にあるデバイスは、接続されている後続のクライアント(スレーブ)のホスト(マスター)として機能します。ホストデバイスが(カメラなどから)受信したデータは、クライアントに転送されます。用途に応じて、クライアントは元のストリームデータ全体を転送するか、その一部のみを転送します。この動作は、デイジーチェーンの終端に達するまでデバイス間で順次繰り返されます。
Basler imaFlex 2 Dual 100 のデータ転送機能を使用すると、画像データだけでなくメタデータも転送できるため、たとえばクライアントデバイスをリモート制御することが可能です。次のセクションでは、これら両方の側面を示す基本的な例について説明します。
サンプルアプレットは、対応するデータ転送用 SDK サンプルアプリケーションで使用するためのものです。 DFMaster および DFSlaveそのため、microDisplay Xなどを介してアプレットを手動でロードする必要はありません。SDK サンプルアプリケーションが自動的にアプレットをロードするため、ユーザー操作はすべてホスト(マスター)アプリケーションを介してのみ行われます。
フレームグラバー SDK スクリプトの使用方法については、VisualApplets インストールディレクトリにある
examples\Acquisition\DataForwarding\SDK 内の対応するスクリプトドキュメントを参照してください。
画像データの転送はシンプルで簡単に実装できます。各サンプルアプレットはその画像パスにこれを示しています。
リモート制御と監視にはより多くの手間が必要です。受信制御コマンドなどの VisualApplets リンクからのデータを使用してアプレットパラメータを動的に変更することはできないためです。この制限は、VisualApplets イベントシステムを使用することで解決できます。リモート制御メタデータパスはこのアプローチを示しています。
アプレットのデザインでは2つのパスが個別に示されていますが、どちらのパスも単一のデバイスペアに対して同じファイバーリソースを共有します。画像データは 0 から 3 まで番号付けされた4つのファイバーレーンすべてを介して送信され、リモート制御データ/メタデータは同じファイバーモジュールのレーン 0 を使用します。
言い換えると、ファイバーモジュールの 2×4 レーンにより、画像とメタデータの両方について2つのデバイスが双方向で接続されます。対応するデータ転送オペレーターである DFTxImage、DFTxMeta、DFRxImage、および DFRxMeta が内部でこれを管理します。
以下の表は、このサンプルで実装されているデータ転送接続をまとめたものです。
サンプルデザインファイルの処理構造についての詳細なドキュメントについては、対応する *.vad デザインのコメントボックスを参照してください。
リモートコントロールにVisualAppletsのイベントシステムを使用する背景には、Framegrabber SDK APIがオペレーターやアプレットのパラメータにアクセスするためのルーチンを提供しているという理由があります。VisualAppletsのイベントシステムを使用すると、ペイロードデータを含むイベントをアプレットからホストPCに送信でき、イベント監視SDKアプリケーションがそのペイロードに応じた処理を行うことができます。
これを踏まえて、リモートコントロールの信号フローは以下のようになります。
-
ホストアプレットがクライアントにコマンドを送信します。
-
クライアントアプレットでは、受信した各制御コマンドがイベント(ペイロード付き)をトリガーします。
-
イベントはフレームグラバーOSドライバーによってキャプチャされます。
-
イベント監視SDKアプリケーションは、イベントペイロードの解釈に従ってSDKルーチンを実行します。
データフォワーディングのサンプルでは、ユーザー定義の通信プロトコルを使用します。この範囲において、コマンドトランザクションはメッセージと呼ばれます。メッセージの構造を以下に示します。
| ビットインデックス | 説明 | サイズ(ビット) |
|---|---|---|
| [55] | 読み取り/書き込みフラグ | 1 |
| [54:48] | クライアント(スレーブ)デバイスアドレス | 7 |
| [47:32] | ソフトウェアアクセス可能なレジスタアドレス | 16 |
| [31:0] | ソフトウェアアクセス可能なレジスタデータ | 32 |
表18:メッセージビットレイアウト
メッセージの合計サイズは56ビットであり、これはDFTxMetaおよびDFRxMetaオペレーターの1データワードのサイズに対応しています。
メッセージトリガーによってメッセージが開始されます。SDKホストアプリケーションは、メッセージの内容とトリガーの両方を設定します。
一般に、VisualAppletsのリンクを流れるデータはさまざまな方法で処理できます。データフォワーディングのサンプルでは、次の2つの処理方法が関連しています。
-
システムはコマンドデータビットを直接使用します。たとえば、専用のビットを次のように変換します。
VALT_SIGNALそしてそれをGPOバンクにルーティングします。 -
システムはVisualAppletsイベントをトリガーし、リモートコマンドから抽出されたペイロードデータを含めることができます。
最初の処理方法はハードウェアコマンドを表します。システムは、メッセージビットを信号ソースとして使用して専用のアクションをトリガーします。2番目の処理方法はソフトウェアコマンドを表します。これは、ドライバーソフトウェアがホストPCに送信されたイベントを処理するためです。データ転送の例では、ソフトウェアコマンドに焦点を当てて、両方のコマンドタイプが実装されています。



前へ

